브라우저의 렌더링과 리액트의 가상 DOM

이번 포스팅에서는 리액트의 가상 DOM에 대해서 알아보고자 한다. 브라우저의 렌더링 과정과 리액트의 렌더링 과정에는 어떠한 차이가 있는지, 그리고 그 과정에서 중요한 역할을 하는 리액트의 가상 DOM이란 무엇인지 알아보겠다.

브라우저의 DOM과 렌더링 과정

리액트의 가상 DOM에 대해 다루기 전에 브라우저의 DOM이 무엇인지 살펴보겠다. 브라우저의 DOM은 Documnet Object Model을 의미하며, 브라우저가 웹페이지를 어떻게 보여줄지에 대한 구조를 담고 있다. 브라우저는 서버로부터 웹페이지에 대한 데이터를 받은 후, 이를 구조화하여 클라이언트에게 보여주기 위해 DOM을 구성하게 된다. 보다 구체적인 설명을 위해 브라우저의 렌더링 과정을 살펴보겠다.

1. 브라우저가 서버로부터 HTML파일을 받는다.
2. 브라우저의 렌더링 엔진은 파일을 실행하기 위해 파싱을 진행한다.
3. 파싱 과정에서 렌더링 엔진은 HTML파일을 문법적 최소 단위인 '토큰'으로 분해하고, 이를 DOM 노드로 객체화한다. 그리고 각 노드들의 관계를 자료구조로 구조화한 DOM 트리를 생성한다.
4. 위의 과정에서 CSS파일을 만나면, HTML 파싱을 잠시 중단하고 CSS파일을 파싱하여 CSSOM 트리를 만든다. CSSOM 트리는 DOM 어떻게 화면에 표시될지 알려주는 역할을 한다.
5. DOM과 CSSOM 트리가 완성되면 이를 화면에 표시하기 위해 렌더트리로 결합한다.
6. 렌더트리가 완성되면 layout, reflow -> paint -> composite 과정을 통해 화면에 파일이 시각적으로 출력된다.

• layout, reflow : 각 노드가 뷰포트의 어느 좌표에 정확히 나타나는지를 계산하는 과정
• paint : layout을 통해 계산된 요소들을 볼 수 있는 형태로 변환하는 과정
• composite : 앞선 과정을 통해 페인팅된 layer를 합성하여 화면에 표시하는 단계

렌더링의 비용

브라우저는 앞선 과정을 통해 웹페이지를 렌더링한다. 하지만 웹페이지를 렌더링하는 것은 많은 비용이 드는 일이다. 렌더링 과정 중 Layout과 Paint 과정에서 많은 비용이 발생하는데, 특히 사용자 인터랙션에 의하여 웹페이지의 스타일이 변경되는 상황이 그러하다. DOM을 조작하는 인터랙션이 발생할 경우, 다시 렌더트리가 결합되며 리렌더링이 발생한다. 이 상황에서 자연스레 Reflow(Layout)과 Re-painting이 발생하며 비용이 증가된다.

리액트 가상 DOM의 탄생

앞선 내용과 같이, 사용자 인터랙션이 많은 현대의 웹어플리케이션의 경우 렌더링에 많은 비용이 소모될 수 있다. 특히 이는 SPA(싱글 페이지 어플리케이션)에서는 더 악화된다. 페이지 마다 서버로부터 파일을 받아오는 MPA(멀티 페이지 어플리케이션)와는 달리, SPA에서는 첫 로딩에 모든 파일이 다운로드되어 브라우저에 렌더링된다. 따라서 사용자 인터랙션이 발생할 경우, 리렌더링에 대한 비용이 더욱 커질 수 있다. 이는 웹페이지의 성능을 체감하는 사용자 뿐 아니라, 성능을 관리해야하는 개발자 입장에서도 곤란한 일이다. 하나의 인터랙션에 의해 여러 가지 DOM이 변경되는 상황들을 추적하기 매우 어려워지기 때문이다. 이러한 문제점들을 해결하기 위해 탄생한 것이 바로 가상 DOM이다. 가상 DOM은 리액트가 관리하는 가상의 DOM을 의미한다. 가상 DOM은 실제 DOM의 복사본으로 메모리에 저장된다.

가상 DOM의 동작원리

- Diffing 알고리즘

리액트는 렌더링 이전의 화면 구조, 그라고 렌더링 이후의 보이게 될 화면 구조를 나타내는 두개의 가상 DOM을 유지한다. 만약 리액트 내부의 State 변경으로 인해 리렌더링이 발생하면, 새로운 내용이 담긴 가상 DOM(두 번째 가상DOM)이 생성된다. 그리고 리액트 내부의 Diffing 알고리즘을 통해 두 가상 DOM을 비교하여, 어떠한 Element들이 변경되었는지를 파악한다. 마지막으로 변경사항이 발생한 부분들만 실제 DOM에 적용하게 된다. 이처럼 리액트는 메모리에 가상 DOM을 관리하는 방법을 통해 SPA에서 문제가 되는 기존 브라우저 DOM처리 방식을 개선하였다.

- Batching

리액트 프로그래밍에서 State 값이 변경될 때마다 리렌더링이 발생한다면 오히려 많은 비용이 발생하지 않을까. 예컨데 한 번의 유저 인터랙션 트리거로 인해 10개의 State들이 변경되는 경우가 있다고 해보자. 이럴 경우 10번의 리렌더링이 발생하는 것은 매우 비효율적일 것이다. 리액트는 Batching을 통해 이러한 상황들을 효율적으로 처리한다. 즉, Batcing은 특정 주기에 변경되어야 하는 상태값들을 모아서 한번에 처리하는 것이라 볼 수 있다.

가상 DOM이 항상 효율적인가

앞선 내용을 통해 리액트의 가상 DOM이 렌더링 작업을 어떻게 효율적으로 처리하는지 알아보았다. 리액트의 가상 DOM은 Diffing 알고리즘과 Batching을 통해 DOM의 업데이트 사항들을 효율적으로 관리한다. 따라서 DOM 연산 최적화에 긍정적인 영향을 미치게 된다.

그렇다면 리액트의 가상 DOM 방식이 성능 측면에서 항상 좋다고 할 수 있을까? 그렇다고 할 수는 없다. 리액트 개발자인 댄 아브라모프(dan_abramov)도 이는 사실이 아니라 부정한 적이 있다. 가상 DOM은 유저 인터랙션이 많은 SPA 프로젝트에 효율적인 도구로 사용될 수 있다. 잦은 DOM 변경으로 인해 심화되는 비용을 관리할 수 있는 방법론이기 때문이다. 반면 유저 인터랙션이 적은 정적인 MPA일 경우에는 기존의 브라우저 DOM 방식이 적합할 수 있다. 이 경우에는 불필요하게 메모리를 사용할 필요가 없으며, 가상 DOM의 추가적인 작업 없이도 빠르게 정보를 전달할 수 있기 때문이다.

마치며

이상 리액트의 렌더링에 대해서 알아보았다. 브라우저의 렌더링 과정에 대해 살펴보고, 브라우저의 렌더링이 유저 인터랙션이 많은 SPA의 경우 많은 비용을 발생시킬 수 있다는 점을 알아보았다. 그리고 이에 대한 해결책으로써 등장한 리액트의 가상 DOM이 무엇이고 어떻게 동작하는지를 살펴보았다. 마지막으로 리액트의 가상 DOM이 항상 효율적이라고 볼 수는 없을 것이다. 현재 진행하는 프로젝트가 어떠한 특성을 가지는지에 따라서 굳이 리액트를 사용할 필요는 없다. 어쩌면 막연하게 리액트를 사용해왔던 것 같다. 어느 프로젝트를 실행하든 리액트를 기본 기술 스택으로 채택한 버릇이 있었다. 유저 인터랙션이 잦은 현대의 웹에서 이를 사용하는 것은 자연스러울지 모른다. 결과적으로도 잘못된 선택은 아니었다. 하지만 이 기술이 어떻게 등장하였고, 어떠한 특성의 어플리케이션을 타깃으로 발전했는지 아는 것이 중요하다고 되돌아보는 시간이다.